Traefik se ha convertido, casi por ósmosis, en el reverse proxy por defecto en entornos Docker Swarm. Su enfoque declarativo por etiquetas, sus certificados Let’s Encrypt casi transparentes, el dashboard que por primera vez hace que entender las rutas de un clúster sea trivial, y un rendimiento muy razonable, lo han dejado como ganador cómodo sobre alternativas clásicas como Nginx o HAProxy. Esta guía está pensada para el momento en el que pasas de «me ha funcionado en local» a «esto tiene que recibir tráfico real», que es un salto menos trivial de lo que parece.
Qué hace falta antes de empezar
Hay cuatro cosas que conviene tener resueltas antes de ejecutar un solo comando. Un clúster Swarm inicializado, aunque sea con un único nodo. Un dominio cuyo registro apunte a la IP pública del manager. Un token de API en el proveedor DNS que uses (Cloudflare, OVH, Route 53, los populares) con permisos para crear registros TXT en la zona. Y una dirección de correo para Let’s Encrypt, que se usa para notificar expiraciones y problemas.
Los puertos 80 y 443 tienen que estar abiertos hacia el manager. Esto parece obvio pero es una de las causas más comunes de errores iniciales: un cortafuegos mal configurado, un proveedor cloud que bloquea el 80 por defecto, un grupo de seguridad aplicado pero no al nodo correcto.
La red sobre la que se hablan los servicios
Traefik necesita una red overlay compartida con los servicios que va a proxyficar. La creación es un paso único:
docker network create --driver=overlay --attachable traefik_publicEl flag --attachable permite que contenedores que no son parte de un servicio Swarm puedan conectarse si fuera necesario. No es imprescindible pero ahorra algunos dolores de cabeza en desarrollo. A partir de aquí, cualquier servicio que declare traefik_public como una de sus redes podrá ser descubierto por Traefik.
Certificados: reto HTTP o reto DNS
Hay dos formas de demostrar a Let’s Encrypt que controlas el dominio. El reto HTTP-01 exige que tu servidor responda a una URL específica en el puerto 80, y funciona bien si solo vas a servir certificados para el dominio que ya está apuntando a ese servidor. El reto DNS-01 exige crear un registro TXT en la zona DNS del dominio, y tiene una ventaja importante: permite pedir certificados wildcard (*.example.com).
Para producción casi siempre prefiero el reto DNS. La razón es que libera a Traefik de tener que recibir tráfico en el puerto 80 durante la validación (lo que facilita escenarios detrás de balanceadores), y permite wildcards, que son cómodos cuando vas a desplegar docenas de subdominios de la misma zona sin querer emitir un certificado individual para cada uno.
La configuración del reto DNS exige declarar, en la configuración estática de Traefik, el proveedor y las credenciales. Para Cloudflare, por ejemplo, se pasan dos variables de entorno (el correo y la clave de API global, o bien un token de API con permisos limitados) al servicio de Traefik. El resto lo gestiona el proveedor: en cuestión de segundos Traefik pide el certificado, el proveedor de DNS crea el TXT, Let’s Encrypt lo valida, y el certificado queda emitido y almacenado.
El almacén de certificados
Let’s Encrypt emite certificados cada noventa días y Traefik los renueva automáticamente. Los guarda en un fichero JSON en disco. Para un único manager, un volumen Docker basta. Para múltiples managers, el fichero debe estar en almacenamiento compartido (NFS, GlusterFS, JuiceFS, lo que uses); de lo contrario, cuando el servicio Traefik se mueva de un nodo a otro, pedirá certificados nuevos desde cero, y Let’s Encrypt tiene cuotas que acabarás pisando.
Este es uno de los detalles que más suele olvidarse. Funciona perfectamente con un nodo, y el día que escalas a un segundo manager empiezas a ver errores misteriosos de cuota. Si anticipas crecer, resuélvelo desde el principio.
La configuración estática y la dinámica
Traefik divide su configuración en dos planos. La estática define cosas que no cambian en caliente: proveedores de descubrimiento (Docker Swarm en nuestro caso), entrypoints (los puertos que escucha), resolvers de certificados, logging. La dinámica define lo que puede cambiar sin reiniciar: rutas, middlewares, servicios. La estática suele estar en traefik.yml; la dinámica vive en las etiquetas de cada servicio o en ficheros adicionales.
En el compose del servicio Traefik, la configuración estática va en un fichero montado como volumen de solo lectura. Allí se declara el resolver ACME con su reto DNS, los dos entrypoints (web para 80, websecure para 443), el proveedor Docker Swarm, y el dashboard si quieres activarlo. No hay nada conceptualmente complejo en este fichero, solo una convención que se aprende leyéndolo una vez con atención.
El dashboard: útil pero hay que protegerlo
El dashboard es una de las mejores partes de Traefik. Te enseña qué rutas están activas, qué middlewares se están aplicando, el estado de cada servicio. La tentación es dejarlo expuesto públicamente «para poder verlo». No lo hagas.
Dos enfoques funcionan bien. Uno, dejarlo solo accesible por red interna (por ejemplo, por VPN WireGuard) sin exponerlo por Traefik mismo. Dos, exponerlo como un servicio más, pero protegido por un middleware de autenticación fuerte (OAuth vía Authentik, Keycloak, o al menos basic auth con credenciales no triviales). El dashboard contiene información que ayuda a un atacante a mapear tu infraestructura.
El primer servicio detrás de Traefik
Una vez desplegado Traefik, exponer un servicio es declarativo. En el compose del servicio de aplicación se añaden etiquetas con el prefijo traefik. que declaran la regla de routing, el entrypoint y el certificado a usar. El patrón mínimo para un servicio web es: una etiqueta traefik.enable=true, una etiqueta traefik.http.routers.<nombre>.rule=Host(\app.example.com`)`, una etiqueta de entrypoint, y una que diga qué puerto interno del servicio hay que proxyficar.
Traefik descubre las etiquetas automáticamente en cuanto el servicio se despliega en Swarm, solicita el certificado si es necesario, y empieza a enrutar. Esa magia es lo que explica la popularidad de Traefik: la configuración vive con el servicio que configura, no en un fichero central de un proxy aparte.
Middlewares: el sitio donde vive la política
Los middlewares son cadenas de funciones aplicadas a peticiones. Los más útiles en producción son:
Redirección de HTTP a HTTPS, que convierte cualquier petición al puerto 80 en una redirección 301 al equivalente HTTPS. Cabeceras de seguridad, que añaden Strict-Transport-Security, X-Frame-Options y similares a cada respuesta. Compresión, que activa gzip y brotli automáticamente. Rate limiting por IP, que amortigua picos y ataques básicos. Autenticación forward a un servidor externo (Authentik o similar) para rutas que requieren login.
Declarar un middleware una vez y aplicarlo a varios routers es lo que hace la configuración manejable. La práctica que mejor funciona es definir cadenas (chains) que agrupan middlewares comunes: una chain-base con redirección, compresión y cabeceras, aplicada a todo lo público; una chain-oauth que añade autenticación forward, aplicada a dashboards y herramientas internas.
Lo que se te va a olvidar la primera vez
Hay un puñado de detalles que, por experiencia, casi todo el mundo pasa por alto al principio.
El logLevel por defecto es demasiado verboso para producción. Bajarlo a INFO reduce ruido sin perder información útil. El log de acceso, en cambio, es enormemente valioso: conviene habilitarlo en formato JSON y canalizarlo a un agregador como Loki o Elasticsearch. Las métricas Prometheus están desactivadas por defecto; activarlas es una línea y permite después construir dashboards útiles.
La autoridad de certificados por defecto de Traefik, si no declaras otra, es la de pruebas de Let’s Encrypt, que emite certificados no válidos para navegadores. Hay que declarar explícitamente la autoridad de producción en el resolver ACME, y la confusión entre ambas produce un flujo clásico de «todo parece funcionar pero los navegadores dicen que el certificado es falso».
Por último, el reinicio del servicio Traefik: aunque Swarm puede reiniciar el servicio sin interrupción aparente, si el almacén de certificados está en un volumen que no es compartido, puedes perder el fichero de certificados durante un reinicio mal gestionado. Los backups del directorio donde vive acme.json son disciplina básica.
Cuándo Traefik no es la respuesta
No todo despliegue merece Traefik. Para servicios muy simples con una única regla estática, un Nginx clásico configurado una vez es más ligero y predecible. Para arquitecturas con routing muy complejo (basado en headers específicos, geo-routing, transformaciones no triviales), HAProxy o Envoy ofrecen más potencia bruta aunque menos comodidad. Para cargas muy grandes con requisitos extremos de rendimiento en CPU limitada, Caddy es interesante y más predecible bajo estrés.
Donde Traefik gana cómodamente es en entornos con muchos servicios pequeños cambiando a menudo, que es exactamente la situación de la mayoría de stacks Swarm. La configuración por etiquetas, la integración nativa con Docker, y los certificados automáticos son el combo ganador.
Mi recomendación
Empieza por lo mínimo: la red overlay, el servicio de Traefik con la configuración estática básica, y un servicio de prueba detrás. No actives el dashboard en producción hasta que tengas el middleware de autenticación resuelto. No intentes configurar todos los middlewares de golpe; añádelos conforme los necesites realmente.
Y cuando la cosa crezca, tómate en serio el almacenamiento compartido del fichero de certificados. Es el tipo de decisión que, mal tomada, te persigue hasta el primer escalado. Todo el resto es ajustable, pero un certificado Let’s Encrypt con cuota quemada te da problemas durante días.
En dos semanas conviviendo con Traefik vas a haberle cogido el ritmo, y después entenderás por qué muchos equipos que lo prueban acaban descartando volver atrás.
